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This brief contains items under the following headings as required by 37 C.F.R. § 41 .37 
and MP.E.P. § 1205.2: 



I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is: 

Hewlett-Packard Development Company, L.P., a Limited Partnership established under 
the laws of the State of Texas and having a principal place of business at 20555 S.H. 249, 
Houston, TX 77070, U.S.A. (hereinafter "HPDC"). HPDC is a Texas limited partnership and is 
a wholly-owned affiliate of Hewlett-Packard Company, a Delaware Corporation, headquartered 
in Palo Alto, CA. The general or managing partner of HPDC is HPQ Holdings, LLC. 
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II. RELATED APPEALS AND INTERFERENCES 

There are no appeals, interferences, or judicial proceedings which will directly affect or 
be directly affected by or have a bearing on the Board's decision in this appeal. 

III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 
There are 25 claims pending in application. 

B. Current Status of Claims 

1. Claims canceled: None 

2. Claims withdrawn from consideration but not canceled: None 

3. Claims pending: 1-25 

4. Claims allowed: None 

5. Claims rejected: 1-25 

C. Claims On Appeal 

The claims on appeal are claims 1-25 
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IV. STATUS OF AMENDMENTS 

A Final Office Action rejecting the claims of the present application was mailed 
August 3, 2007. In response, Applicant did not file an Amendment After Final Rejection, but 
instead filed a Notice of Appeal, which this brief supports. Accordingly, the claims on appeal 
are those as rejected in the Final Office Action of August 3, 2007. A complete listing of the 
claims is provided in the Claims Appendix hereto. 
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V. S UMMARY OF CLAIMED SUBJECT MATTER 

The following provides a concise explanation of the subject matter defined in each of the 
separately argued claims involved in the appeal, referring to the specification by page and line 
number and to the drawings by reference characters, as required by 37 C.F.R. § 41 .37(c)(l)(v). 
Each element of the claims is identified by a corresponding reference to the specification and 
drawings where applicable. It should be noted that the citation to passages in the specification 
and drawings for each claim element does not imply that the limitations from the specification 
and drawings should be read into the corresponding claim element. 

According to one claimed embodiment, such as that of independent claim I,, a method 
comprises determining (see operational block 700 of FIGURE 7 and paragraphs 0005 and 0029 
of the specification) a construction design for an adapted portal application. The method further 
comprises determining (see operational block 701 of FIGURE 7 and paragraphs 0005 and 0029 
of the specification) a model for separation or presentation logic and application logic of an 
existing Web application to be adapted into said portal application; and determining (see 
operational block 702 of FIGURE 7 and paragraphs 0005 and 0029 of the specification) a 
navigation construction for said adapted portal application. The method further comprises 
selecting (see operational block 703 of FIGURE 7 and paragraphs 0005 and 0029 of the 
specification) a level of customization to apply to said adapted portal application; and selecting 
(see operational block 704 of FIGURE 7 and paragraphs 0005 and 0029 of the specification) an 
isolation model for isolating business logic from said adapted portal application. The method 
further comprises employing the determined construction design, the determined model, the 
determined navigation construction, the selected level of customization, and the selected 
isolation model for adapting said existing Web application into said porta! application in a 
manner that maintains said existing Web application's functionality within said portal 
application, see e.g., paragraphs 0022-0023 and 0027 of the specification.. 

In certain embodiments, such as that of dependent claim 3, the determining a navigation 
construction includes one or more of: retrieving selected information based on an event defined 
by uniform resource locator (URL) interaction in said Web application; and creating a new 
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window for information retrieved in response to a call to said URL from said Web application, 
see paragraphs 0018, 0020-0023, and 0028 of the specification. 

According to another claimed embodiment, such as that of independent claim 6, a method 
for adapting a Web application to a portal application comprises adding (see operational block 
300 of FIGURE 3 and paragraphs 0006 and 0022-0023 of the specification) at least one 
component of said Web application to a portal platform. The method further comprises creating 
(see operational block 301 of FIGURE 3 and paragraphs 0006 and 0022-0023 of the 
specification) a plurality of portlets within said portal platform, wherein each of said plurality 
includes pages representing a view for said at least one component of said Web application; and 
defining (see operational block 302 of FIGURE 3 and paragraphs 0006 and 0022-0023 of the 
specification) at least one Web flow relationship representing interactions between said at least 
one component of said Web application. The method further comprises converting (see 
operational block 303 of FIGURE 3 and paragraphs 0006 and 0022-0023 of the specification) 
said at least one Web flow relationship into at least one event, defined within said plurality of 
portlets, wherein said at least one event corresponds to said interactions. 

According to another claimed embodiment, such as that of independent claim 1 1, a 
methodology for converting a Web application into a portal application comprises moving (see 
operational block 500 of FIGURE 5 and paragraphs 0007 and 0027 of the specification) Web 
components from said Web application into a portal framework corresponding to said portal 
application. The method further comprises dividing (see operational block 501 of FIGURE 5 
and paragraphs 0007 and 0027 of the specification) said portal application into a plurality of 
portlets, wherein each of said plurality serves content of one or more or said Web applications; 
and providing (see operational block 502 of FIGURE 5 and paragraphs 0007 and 0027 of the 
specification) navigation resources to said portal application. 

In certain embodiments, such as that of dependent claim 19, the providing step comprises 
one or more of: converting uniform resource locator (URL) calls from said Web application to 
interaction events for said portal application; and creating a new window for information 
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retrieved in response to a call to said URL from said Web application, see paragraphs 0018, 
0020-0023, and 0028 of the specification. 

According to another claimed embodiment, such as that of independent, claim 21, a 
system for adapting a Web application to a portal application comprises means (e.g., computer- 
executable software code executing on a computer, see e.g., paragraphs 0020-0023 of the 
specification) for adding (see operational block 300 of FIGURE 3 and paragraphs 0008 and 
0022-0023 of the specification) one or more Web application components to said portal 
application. The system further comprises means (e.g., computer-executable software code 
executing on a computer, see e.g., paragraphs 0020-0023 of the specification) for generating (see 
operational block 301 of FIGURE 3 and paragraphs 0008 and 0022-0023 of the specification) a 
plurality of portlets within said portal application, wherein each of said plurality includes a view 
for said one or more Web application components. The system further comprises means (e.g., 
computer-executable software code executing on a computer, see e.g., paragraphs 0020-0023 of 
the specification) for defining (see operational block 302 of FIGURE 3 and paragraphs 0008 and 
0022-0023 of the specification) at least one Web flow relationship representing interactions 
between said one or more Web application components; and means (e.g., computer-executable 
software code executing on a computer, see e.g., paragraphs 0020-0023 of the specification) for 
converting (see operational block 303 of FIGURE 3 and paragraphs 0008 and 0022-0023 of the 
specification) said at least one Web flow relationship into at least one interaction event, defined 
within said plurality of portlets, wherein said at least one interaction event corresponds to said 
interactions. 

In certain embodiments, such as that of dependent claim 24, the system further comprises 
means (e.g.. computer-executable software code executing on a computer, see e.g., paragraphs 
0020-0023 of the specification) for modifying business logic of said one or more Web 
application components to return output as a data-descriptive meta language document, see 
paragraph 0028 of the specification. 
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VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 1-25 are rejected under 35 U.S.C. § 102(b) as being anticipated by U.S. Patent 
No. 6,327,628 issued to Anuff et al. (hereinafter "AnufT). 
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VII. ARGUMENT 

Appellant respectfully traverses the outstanding rejections of the pending claims, and 
requests that the Board reverse the outstanding rejections in light of the remarks contained 
herein. The claims do not stand or fall together. Instead, Appellant presents separate arguments 
for various independent and dependent claims. Each of these arguments is separately argued 
below and presented with separate headings and sub-heading as required by 37 C.F.R. § 
4L37(c}(l)(vii). 

A. Rejections Under 35 U.S.C. §102(b) over Anuff 

Claims 1-25 are rejected under 35 U.S.C. § 102(b) as being anticipated by Anuff. 
Appellant respectfully traverses this rejection below. 

To anticipate a claim under 35 U.S.C. § 102, a single reference must teach every element 
of the claim, see M.P.E.P. § 2131. Thus, § 102 anticipation is not found when the applied art is 
lacking or missing a specific feature or the structure of the claimed invention. Further, the 
Federal Circuit has explained: "There must be no difference between the claimed invention and 
the reference disclosure, as viewed by a person of ordinary skill in the field of the invention." 
Scripps Clinic & Research Found, v. Genentech Inc., 927 F.2d 1565 (Fed. Cir. 1991). As 
discussed further below, claims 1-25 are not anticipated under § 102 by Anuffbsc&ust Anuff tails 
to teach each and every element of these claims as required by M.P.E.P. § 2131. 
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Independent Claim 1 and Dependent Claims 2 and 4-5 



Claim 1 recites: 

A method comprising: 

determining a construction design for an adapted portal application; 

determining a model for separation or presentation logic and application 
logic of an existing Web application to be adapted into said portal application; 

determining a navigation construction for said adapted portal application; 

selecting a level of customization to apply to said adapted portal 
application; 

selecting an isolation model for isolating business logic from said adapted 
portal application; and 

employing the determined construction design, the determined model, the 
determined navigation construction, the selected level of customization, and the 
selected isolation model for adapting said existing Web application into said 
portal application in a manner that maintains said existing Web application's 
functionality within said portal application . (Emphasis added). 

Anuff Mis to teach all elements of claim 1. Anuff is directed generally to a portal 
infrastructure, and in particular to a modular portal infrastructure, see e.g., the Abstract of Anuff. 
While Anuff proposes a modular portal infrastructure or framework, Anuff Mis to address any 
technique for adapting an existing Web application into the proposed portal infrastructure. 

Anuff recognizes that a desire may exist to enable a user "to have quick access to various 
resources and data provided by the employer, while at the same time being able to view 
information provided over the Internet, such as news headlines, financial data, and vendor data." 
Col. 3, lines 32-36. "To this end, therefore, portals have become popular mechanisms that 
enable users to access information from multiple different network sites at once." Col. 3, lines 
36-39. Thus, Anuff proposes a modular portal framework, wherein by "interacting with any one 
of these modules, the user can access the information or servicees provided by that module." 
Col. 4, lines 1-3. "Thus, by clicking on a headline in the 'News' module, the user can be 
presented with the full text of the news story to which the headline pertains." Col. 4, lines 3-5. 



Again, while Anuff proposes such modules to be employed in its portal framework, Anuff 
fails to address any technique for adapting an existing Web application in the proposed modular 
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portal framework. For instance, Anuff Tails to disclose a technique for adapting an existing Web 
application to form a corresponding module to be used in its portal framework. 

Accordingly, Anujf fails to disclose at least "employing the determined construction 
design, the determined model, the determined navigation construction, the selected level of 
customization, and the selected isolation model for adapting said existing Web application into 
said portal application in a manner that maintains said existing Web application's functionality 
within said portal application", as recited by claim 1. 

In response to the above arguments, the Final Office Action raises an issue concerning 
the interpretation of the recited '"existing Web application". "The Examiner realizes that Anuff 
does not explicitly teach a technique that takes coded components, in other words an instance of 
an implementation, of a Web application and modify or incorporate those coded components to 
form, corresponding modules to be used in its portal framework", page 7 of the Final Office 
Action. However, the Examiner contends that the recited "existing Web application" can be 
reasonably more broadly interpreted to mean a "concept of a Web application", which appears to 
refer to any functionality that may be performed via the Web. For instance, the Final Office 
Action asserts on page 7 thereof: 

A "Web application" as recited in the claim, can reasonably be interpreted, 
in the broadest reasonable interpretation, to mean a concept of a Web application. 
For example, just the concept of searching the web with a keyword for retrieving 
information relevant to the keyword can be broadly referred to as a Web 
application, even though this concept can be implemented using various different 
techniques as various different instances of implementation of the Web 
application. Therefore, "an existing Web application" as recited in the claim can 
reasonably be interpreted to mean "a known concept of a Web application" and 
not necessarily be interpreted to be an existing instance of a particular 
implementation of a Web application. 

Appellant respectfully disagrees, and submits that the Examiner's interpretation of an 
"existing Web application" as a known concept of a Web application (which appears to refer to a 
known functionality that is performed via the Web, such as the concept of performing keyword 
searching over the web) is unreasonably broad. The claim language should be interpreted 
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consistent with the specification of the application. That is, the claims are to be given their 
broadest reasonable interpretation in light of the specification, see M.P.E.P. §2111. "Claims are 
not to be read in a vacuum, and limitations therein are to be interpreted in light of the 
specification in giving them their 'broadest reasonable interpretation'." M.P.E.P. §2111 .01(11), 
quoting In re Marosi,l\Q F.2d 799, 218 USPQ 289 (Fed. Cir. 1983). Indeed, if read in a 
vacuum, the word "Web" could be interpreted as a spider web, rather than the well-known 
computer network referred to as the "Web". Likewise, when properly interpreted in light of its 
usage in the specification of the present application, "an existing Web application" is not 
reasonably interpreted as referring to any known function (or concept) than can be performed via 
the Web. 

In referring to adapting an existing Web application into a portal framework, the present 
application consistently refers to such an existing Web application as being, in the words of the 
Examiner, an instance of an implementation of a Web application, rather than a concept of a 
Web application. For instance, in paragraph 0027, the present application describes that a "Web 
application is typically constructed from a number of Web components appropriately coded by 
the developer that provide some information or application logic to the user." Paragraph 0027 
goes on to describe that "the code underlying the Web components are moved by the developer 
from the Web application into a portal framework corresponding to the portal application." An 
example is further provided in paragraph 0023, which states that "an existing HTML page may 
include several different components that provide data to present to a user over the Web 
browser." 

Thus, the recited "existing Web application" is not reasonably interpreted as referring to 
any known function (or "concept") that may be performed via the web, as asserted by the 
Examiner, when considered consistent with its use in the specification of the present application. 
When this term of the claim is afforded a reasonable interpretation, Anuff "fails to teach the 
above-emphasized element of claim 1, as conceded by the Examiner ("The Examiner realizes 
that Anuff does not explicitly teach a technique that takes coded components, in other words an 
instance of an implementation, of a Web application and modify or incorporate those coded 
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components to form corresponding modules to be used in its portal framework", page 7 of the 
Final Office Action). 

Therefore, Anuff fails to anticipate claim 1 . Accordingly, Appellant requests that the 
Board overturn this rejection. 

Claims 2 and 4-5 each depend either directly or indirectly from independent claim 1, and 
are thus likewise believed to be allowable at least based on their dependency from claim 1 for the 
reasons discussed above. Accordingly, Appellant respectfully requests that the rejection of 
claims 2 and 4-5 also be overturned. 

Dependent Claim 3 

Dependent claim 3 depends from claim 1, and thus inherits all of the limitations of claim 
1 in addition to its own supplied limitations. It is respectfully submitted that dependent claim 3 
is allowable at least because of its dependence from claim 1 for the reasons discussed above. 

Claim 3 further recites "wherein said determining a navigation construction includes one 
or more of: retrieving selected information based on an event defined by uniform resource 
locator (URL) interaction in said Web application; and creating a new window for information 
retrieved in response to a call to said URL from said Web application " (emphasis added). Anuff 
further fails to teach creating a new window for information retrieved in response to a call to a 
URL from a Web application. Thus, this further element of claim 3 is not taught by Anuff, and 
the rejection of claim 3 should therefore be overturned for this further reason. 
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Claim 6 recites: 

A method for adapting a Web application to a portal application 
comprising: 

adding at least one component of said Web application to a portal 
platform; 

creating a plurality of portlets within said portal platform, wherein each of 
said plurality includes pages representing a view for said at least one component 
of said Web application; 

defining at least one Web flow relationship representing interactions 
between said at least one component of said Web application : and 

converting said at least one Web flow relationship into at least one eve nt, 
defined within said plurality of portlets. wherein said at least one event 
corresponds to said interactions . (Emphasis added). 

Anuff fails to teach all elements of claim 6. As discussed above with claim 1, Anuff xs, 
directed generally to a portal infrastructure, and in particular to a modular portal infrastructure, 
see e.g.. the Abstract of Anuff. While Anuff proposes a module portal infrastructure or 
framework, Anuff Mis to address any technique for adapting an existing Web application into the 
proposed portal infrastructure. Thus, Anuff fails to disclose a method for "adapting a Web 
application to a portal application" in the manner recited by claim 6. 

Further, the method of claim 6 for so adapting a Web application to a portal application 
recites, in part, "defining at least one Web flow relationship representing interactions between 
said at least one component of said Web application: and converting said at least one Web flow 
relationship into at least one event, defined within said plurality of portlets, wherein said at least 
one event corresponds to said interactions." Anuff fails to disclose at least these steps of the 
method. Again, Anuff Mis to disclose any technique for adapting a web application to its 
proposed modular portal infrastructure. While Anuff discloses modules, Anuff does not disclose 
that adapting a web application to such a module includes defining at least one Web flow 
relationship representing interactions, and converting the Web flow relationship into at least one 
event, defined within the portlets, as recited by claim 6. 
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The Final Office Action asserts on page 5 thereof that "defining at least one Web flow 
relationship is inherent in the reference since there has to be a defined Web flow relationship in 
order to show the appropriate page based on the user interaction at the portal". Further, the 
Office Action asserts on pages 5-6 thereof that "Amiff teaches implementing the defined Web 
flow relationship by converting it into user selection events such as selecting a link or button in 
order to display appropriate page based on the selection". However, this appears to focus on the 
proposed functionality of a given module that is implemented within Anuff's portal framework, 
rather than a process for adapting an existing Web application into the portal (e.g., into the given 
module). For instance, while the operation of a given module within Anuff's portal may support 
a certain flow of interaction with a user by enabling the user to click on a hyperlink, etc., Anuff 
fails to disclose defining a Web flow relationship for a Web application and converting such 
relationship into an event defined in a portlet of a portal in order to adapt a Web application into 
such portal (e.g., in order to adapt a Web application into a module). Indeed, the modules of 
Anuff may be created from scratch, rather than attempting to adapt an existing Web application 
into such modules, as Anuff provides no disclosure of any such adapting of an existing Web 
application into its portal framework. 

Further, as discussed above with claim 1 , "existing Web application" is not properly 
interpreted as referring to any known Web concept. Indeed, claim 6 expressly recites that the 
Web application has at least one component, and a Web flow relationship is defined representing 
interactions between said at least one component of said Web application. See e.g., paragraphs 
0022-0023 and 0027 of the present application. Accordingly, interpretation such an existing 
Web application as a known concept (or function) of the web is particularly unreasonably broad 
with regard to claim 6, which expressly recites that the Web application comprises at least one 
component. 

Accordingly, Anuff fails, to disclose at least the above-identified elements of claim 6. 
Therefore, Appellant respectfully requests that this rejection be overturned. 

Claims 7-10 each depend either directly or indirectly from independent claim 6, and are 
thus likewise believed to be allowable at least based on their dependency from claim 6 for the 
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reasons discussed above. Accordingly, Appellant respectfully requests that the rejection of 
claims 7-10 also be overturned. 

Independent Claim 11 and Dependent Claims 12-18 and 20 

Claim 1 1 recites: 

A methodology for converting a Web application into a portal application 
comprising: 

moving Web components from said Web application into a portal 
framework corresponding to said portal application : 

dividing said portal application into a plurality of portlets, wherein each of 
said plurality serves content of one or more or said Web applications; and 

providing navigation resources to said portal application. (Emphasis 

added). 

Anuff Mis to teach all elements of claim 1 1. As discussed above with claim 1, Anuff is 
directed generally to a portal infrastructure, and in particular to a modular portal infrastructure, 
see e.g. , the Abstract of Anuff. While Anuff proposes a module portal infrastructure or 
framework, Anuff Mis to address any technique for converting a Web application into the 
proposed portal infrastructure. Thus, ^/tw^f fails to disclose a method for "converting a Web 
application into a portal application" in the manner recited by claim 1 1. 

Further, the method of claim 1 1 for so converting a Web application into a portal 
application recites, in part, "moving Web components from said Web application into a portal 
framework corresponding to said portal application". Anuff "fails to disclose at least this step of 
the method. Again, Anuff fails to disclose any technique for converting a web application to its 
proposed modular portal infrastructure. While Anuff discloses modules, Anuff 'does not disclose 
that adapting a web application to such a module includes moving Web components from said 
Web application into a portal framework (e.g., module), as recited by claim 1 1 . Indeed, the 
modules of Anuff may be created from scratch, rather than attempting to convert an existing Web 
application into such modules, as Anuff provides no disclosure of any such converting of an 
existing Web application into its portal framework. 
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Moreover, as discussed above with claim 1, "existing Web application" is not properly 
interpreted as referring to any known Web concept. Indeed, claim 1 1 expressly recites that the 
Web application has at least one component, and a Web flow relationship is defined representing 
interactions between said at least one component of said Web application. See e.g., paragraphs 
0022-0023 and 0027 of the present application. Accordingly, interpretation such an existing 
Web application as a known concept (or function) of the web is particularly unreasonably broad 
with regard to claim 11, which expressly recites that the Web application comprises at least one 
component. 

Accordingly. Amijf fails to disclose at least the above-identified elements of claim 11. 
Therefore, Appellant respectfully requests that this rejection be overturned. 

Claims 12-18 and 20 each depend either directly or indirectly from independent claim 11, 
and are thus likewise believed to be allowable at least based on their dependency from claim 1 1 
for the reasons discussed above. Accordingly, Appellant respectfully requests that the rejection 
of claims 12-18 and 20 also be overturned. 

Dependent Claim 19 

Dependent claim 19 depends from claim 11, and thus inherits all of the limitations of 
claim 1 1 in addition to its own supplied limitations. It is respectfully submitted that dependent 
claim 19 is allowable at least because of its dependence from claim 1 1 for the reasons discussed 
above. 

Claim 19 further recites "wherein said providing step comprises one or more of: 
converting uniform resource locator (URL) calls from said Web application to interaction events 
for said portal application; and creating a new window for information retrieved in response to a 
call, to said URL from said Web application " (emphasis added). Anuff further fails to teach 
creating a new window for information retrieved in response to a call to a URL from a Web 
application. Thus, this further element of claim 19 is not taught by Anuff, and the rejection of 
claim 19 should therefore be overturned for this further reason. 
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independent Claim 21 and Dependent Claims 22-23 and 25 

Claim 21 recites: 

A system for adapting a Web application to a portal application 
comprising: 

means for adding one or more Web application components to said portal 
application; 

means for generating a plurality of portlets within said portal application, 
wherein each of said plurality includes a view for said one or more Web 
application components; 

means for defining at least one Web flow relationship representing 
interactions between said one or more Web application components: and 

means for converting, said at least one Web flow relationship into at least 
one interaction even t, defi ned within said plurality of portlets. wherein said at 
least one interaction event corresponds to said interactions . (Emphasis added). 

AnufffaWs to teach all elements of claim 21. As discussed above with claim 1, Anuff is 
directed generally to a portal infrastructure, and in particular to a modular portal infrastructure, 
see e.g., the Abstract of Anuff While Anuff proposes a module portal infrastructure or 
framework, Anuff 'fails to address any technique for adapting a Web application into the proposed 
portal infrastructure. Thus, Anuff fails to disclose a system for "adapting a Web application to a 
portal application" in the manner recited by claim 21. 

Further, the system of claim 21 for so adapting a Web application to a portal application 
recites, in part, "means for defining at least one Web flow relationship representing interactions 
between said one or more Web application components; and means for converting said at least 
one Web flow relationship into at least one interaction event, defined within said plurality of 
portlets, wherein said at least one interaction event corresponds to said interactions." Anuff Mis 
to disclose at least these means of the system. Again, AnuffMh to disclose any technique for 
adapting a web application to its proposed modular portal infrastructure. While Anuff discloses 
modules, Anuff does not disclose that adapting a web application to such a module includes use 
of a means for defining at least one Web flow relationship representing interactions, and means 
for converting the Web flow relationship into at least one interaction event, defined within the 
portlets, as recited by claim 21. Indeed, as mentioned with claim 6 above, the modules of Anuff 
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may be created from scratch, rather than attempting to adapt an existing Web application into 
such modules, as Anuff provides no disclosure of any such adapting of an existing Web 
application into its portal framework. 

Moreover, as discussed above with claim 1, the recited "Web application" is not properly 
interpreted as referring to any known Web concept. Indeed, claim 21 expressly recites one or 
more Web application components. Accordingly, interpretation such a Web application as a 
known concept (or function) of the web is particularly unreasonably broad with regard to claim 
21, which expressly recites one or more Web application components. 

Accordingly, Anuff (ails to disclose at least the above-identified elements of claim 21 . 
Therefore, Appellant respectfully requests that the rejection of claim 21 be overturned. 

Claims 22-23 and 25 each depend either directly or indirectly from independent claim 21, 
and are thus likewise believed to be allowable at least based on their dependency from claim 21 
for the reasons discussed above. Accordingly, Appellant respectfully requests that the rejection 
of claims 22-23 and 25 also be overturned. 

Dependent Claim 24 

Dependent claim 24 depends from claim 21, and thus inherits all of the limitations of 
claim 21 in addition to its own supplied limitations. It is respectfully submitted that dependent 
claim 24 is allowable at least because of its dependence from claim 21 for the reasons discussed 
above. 

Claim 24 further recites "means for modifying business logic of said one or more Web 
application components to return output as a data-descriptive meta language document". Anuff 
further fails to teach modifying business logic of a Web application component to return output 
as a data-descriptive meta language document. Thus, this further element of claim 24 is not 
taught by Anuff, and the rejection of claim 24 should therefore be overturned for this further 
reason. 



5?! 10155 : 



19 



Application No.: 10/765,378 



Docket No.; 200313705-1 



Conclusion 

In view of the above, Appellant requests that the board overturn the outstanding 
rejections of claims 1-25. Attached hereto are a Claims Appendix, Evidence Appendix, and 
Related Proceedings Appendix. As noted in the attached Evidence Appendix, no evidence 
pursuant to §§ 1.130, 1.131, or 1.132 or entered by or relied upon by the examiner is being 
submitted. Also, no related appeals are identified in Section II above, and thus as noted by the 
Related Proceedings Appendix, no decisions in any such related proceedings are provided. 
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VHI. CLAIMS APPENDIX 
Claims Involved in the Appeal of Application Serial No. 10/765,378 

1 . (Previously Presented) A method comprising: 
determining a construction design for an adapted portal application; 
determining a model for separation or presentation logic and application logic of an 

existing Web application to be adapted into said portal application; 

determining a navigation construction for said adapted portal application; 

selecting a level of customization to apply to said adapted portal application; 

selecting an isolation model for isolating business logic from said adapted portal 
application; and 

employing the determined construction design, the determined model, the determined 
navigation construction, the selected level of customization, and the selected isolation model for 
adapting said existing Web application into said portal application in a manner that maintains 
said existing Web application's functionality within said portal application. 

2. (Original) The method of claim 1 wherein said determining a construction design 
includes one or more of: 

determining a visual theme of said adapted portal application; and 
determining a format of content for said adapted portal application. 

3. (Original) The method of claim 1 wherein said determining a navigation 
construction includes one or more of: 

retrieving selected information based on an event defined by uniform resource locator 
(URL) interaction in said Web application; and 

creating a new window for information retrieved in response to a call to said URL from 
said Web application. 

4. (Original) The method of claim 1 wherein said selecting a level of customization 
comprises one or more of: 



Application No.: 10/765,378 



Docket No.: 200313705-1. 



presenting an interactive window to obtain customization information from a user, 
wherein said obtained customization information is stored in a portal framework; and 

retrieving existing login information related to said user for inclusion in content of said 
adapted portal application. 

5. (Previously Presented) The method of claim 1 wherein said selecting an isolation 
model comprises one or more of: 

modifying said business model to return output as at least one data-descriptive meta 
language document; and 

creating a component to connect said adapted portal application to one or more Web 
services for providing said business logic to said adapted portal application. 

6. (Original) A method for adapting a Web application to a portal application 
comprising: 

adding at least one component of said Web application to a portal platform; 

creating a plurality of portlets within said portal platform, wherein each of said plurality 
includes pages representing a view for said at least one component of said Web application; 

defining at least one Web flow relationship representing interactions between said at least 
one component of said Web application; and 

converting said at least one Web flow relationship into at least one event, defined within 
said plurality of portlets, wherein said at least one event corresponds to said interactions. 

7. (Original) The method of claim 6 further comprising: 

creating a customization application for obtaining customization information from a user. 

8. (Original) The method of claim 7 further comprising: 

defining a storage utility to store said customization information to said portal platform. 

9. (Original) The method of claim 6 further comprising: 

modifying business logic to return output as a data-descriptive meta language document. 
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1 0. (Original) The method of claim 6 further comprising: 
creating a client interface to search a plurality of Web services; 

coding said client interface to select one or more of said plurality of Web services to 
provide business logic to said portal application. 

1 1. (Original) A methodology for converting a Web application into a portal 
application comprising: 

moving Web components from said Web application into a portal framework 
corresponding to said portal application; 

dividing said portal application into a plurality of portlets, wherein each of said plurality 
serves content of one or more or said Web applications; and 

providing navigation resources to said portal application. 

12. (Original) The methodology of claim 1 1 further comprising: 

designing a construction layout for said plurality of portlets responsive to one or more of: 
a visual theme of said portal application; and 
content formatting of said portal application. 

13. (Original) The methodology of claim 1 1 further comprising: 
selecting customization to apply to said portal application. 

14. (Original) The methodology of claim 13 wherein said selecting customization 
comprises one or more of: 

presenting a user interface to a user to gather customization information; and 
obtaining personal, login information, from said portal framework related to said user. 

15. (Original) The methodology of claim 14 wherein said customization information 
is stored within said portal framework for customization. 

1 6. (Original) The methodology of claim 14 further comprising: 

displaying a second user interface to a user for updating said personal login information. 
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17. (Original) The methodology of claim 1 1 further comprising: 
isolating process logic from said portal application. 

18. (Original) The methodology of claim 17 wherein said isolating comprises one or 
more of: 

modifying said process logic to output at least one data-descriptive meta language 
document; and 

receiving process output from one or more Web services. 

19. (Original) The methodology of claim 1 1 wherein said providing step comprises 
one or more of: 

converting uniform resource locator (URL) calls from said Web application to interaction 
events for said portal application; and 

creating a new window for information retrieved in response to a call to said URL from 
said Web application. 

20. (Original) The methodology of claim 19 further comprising: 
retrieving information related to said URL on detection of said interaction events. 

21. (Original) A system for adapting a Web application to a portal application 
comprising: 

means for adding one or more Web application components to said portal application; 

means for generating a plurality of portlets within said portal application- wherein each of 
said plurality includes a view for said one or more Web application components; 

means lor defining at least one Web flow relationship representing interactions between 
said one or more Web application components; and 

means for converting said at least one Web flow relationship into at least one interaction 
event, defined within said plurality of portlets, wherein said at least one interaction event 
corresponds to said interactions. 
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22. (Original) The system of claim 21 further comprising: 

means for creating a customization interface for obtaining customization information 
from a user. 

23. (Original) The system of claim 22 further comprising: 

means for generating a storage utility to store said customization information in said 
portal application. 

24. (Original) The system of claim 21 further comprising: 

means for modifying business logic of said one or more Web application components to 
return output as a data-descriptive meta language document. 

25. (Original) The system of claim 21 further comprising: 

means for creating a service interface to search a plurality of Web services; and 
means for coding said service interface to select one or more of said plurality of Web 
services to provide business logic to said portal application. 



55N6155.I 



25 



Application No.: 10/765,378 



Docket No.: 200313705-1 



IX. EVIDENCE APPENDIX 

No evidence pursuant to §§ 1.130, 1.131, or 1.132 or entered by or relied upon by the 
examiner is being submitted. 
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X. RELATED PROCEEDINGS APPENDIX 

There are no appeals, interferences, or judicial proceedings which will directly affect or 
be directly affected by or have a bearing on the Board's decision in this appeal, and thus no 
copies of any decisions in any such related proceedings are provided. 
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